Computer systems communicatively coupled in a network environment are enabled to share data among the coupled computer systems. Currently; a wide variety of networking components are available to facilitate communicative coupling of computer systems. Examples of network components can be hardware devices including, but not limited to, hubs, switches, NICs (network interface cards), routers, bridges, servers, cabling (e.g., CAT 5) to connect the devices, ROM (read only memory) chips that contain instructions for hardware devices, cooling devices for the case in which servers are located, cases for the servers, rack enclosures, etc. Other examples of network components can be, but not limited to, software code for providing instructions to hardware components, e.g., input/output software (I/O software) which controls network traffic, software tools, e.g., remote monitoring, fault detection, troubleshooting, environment condition monitoring, and the like.
Accordingly, a network component can be hardware, software, or a combination of hardware and software. Also, it is common for each network component to have certain physical, operational, and/or performance characteristics/properties associated therewith. Further, each network component may have characteristics/properties contingent upon other network components with which it is coupled and the manner in which they are configured. Accordingly, proper configuration is vital when complex network components are involved.
When a customer acquires a network component or components in conjunction with development of a network of communicatively coupled computer systems, or when acquiring components for upgrades or adding to existing networks, there are a myriad of possible options and configurations available that are dependent upon the network architecture and topology. Within a network architecture and/or topology being developed, upgraded, or increased, some network components may not be compatible with other network components.
Having incompatible components in a network can be especially disadvantageous to customers who acquire large numbers of network components, e.g., large companies and/or multi-national corporations, because the customer's network architecture would require some measure of redesigning to remedy the non-compatibility of some components, not to mention the re-initiation of the purchasing process. Redesigning a network architecture, partially or entirely, or reinitiating the purchasing process can add substantial expense to costs associated with network development and implementation.
Further disadvantageous is when a customer, e.g., a large company/corporation, needs to change or upgrade components within the existing network architecture and/or topology. Some changes to network components, e.g., hardware and/or software, or the upgrades thereof can, in some instances, render other network components coupled to the existing network inoperable. In some instances, this can require the customer to redesign their portions of their network architecture and/or topology to remedy the inoperability of some network components, which can also add substantial expense to the overall cost of maintaining the network architecture and/or topology.
In many instances, the code for a software component undergoes various changes for a wide variety of reasons, e.g., bug fixes, security patches, updates, etc. Some software component changes may not support certain network components and/or render some network components inoperable, such that the consumer may need to replace certain components. Additionally, a change in a software component may not support or may render other software components inoperable. Further disadvantageous is that, in many instances, new software components may not be compatible with some of the existing software components, thus adding substantial expense to the cost of the network.
Generally, in an electronic environment for ordering network components, when a customer, e.g., an individual, a company/corporation, an institution, etc., is developing a network or upgrading or increasing an existing network architecture and/or topology, that customer accesses a web site of a network component supplier, select components, configures the selected components and then submits the purchase order. In a B2C (business-to-customer) environment where information regarding the configuration of the network component is stored on the supplier's systems, this practice may be acceptable. Customer's interaction with the supplier is real-time and the customer can take additional measures if configurations become invalid. In this B2C scenario, the configuration of the network components is checked at the time of ordering.
However, in a B2B (business-to-business) environment, generally, the customer receives component information and pricing via a supplier's XML (extensible markup language) document/web page or from a supplier's Internet web page. In some instances, the customer then creates the configuration through the Web (in this instance, if the customer utilizes a Web based configurator) and then transfers the configuration to their ERP (enterprise resource planning) system, or through utilization of custom configuration tools, e.g., a CND (computer network designer), or similar configuration tool. In other instances, the customer may manually enter the configuration into a spreadsheet application. A partner of the customer stores the configuration information in their system. The stored configurations are quite volatile to change in component configuration on the supplier's side. If the partner submits the configuration as part of a component order, the configuration can be valid or invalid. If the configuration is valid, the order can be accepted. Alternatively, if invalid, the partner needs to correct the configuration and then resubmit the order. In many instances, this causes a reinitiating of the purchasing approval process on the partner side, thus adding substantial expense to the cost of the network. In this B2B scenario, the configuration is checked after ordering.
Accordingly, current network component configuration checking mechanisms and/or methods provide for checking of the configuration concurrent with or until after the ordering of the network components, thus causing increased costs associated with network development, implementation, upgrades, and the like. Thus, a need exists for a method that validates the configuration of network components prior to order submission.